Harden UDT assembly loading against server-supplied assembly names - #4591

SqlConnection.ResolveTypeAssembly handed the assembly name carried by a
server-supplied UDT assembly-qualified name straight to Assembly.Load,
and GetUdtValue then invoked a static member on the resolved type
without checking that it was a user-defined type at all. Loading an
assembly runs its module initializer and invoking a static member runs
the type's static constructor, so a compromised or hostile server -- or
an attacker on the network path of a connection that has opted out of
certificate validation -- could choose which code the client process
executes.

Add a deny-by-default policy that decides whether an assembly may be
loaded before the name reaches the loader:

- Restricted (default) permits Microsoft.SqlServer.Types, the
  application's allow list, assemblies already loaded into the process,
  and assemblies statically referenced by them.
- Strict, via Switch.Microsoft.Data.SqlClient.UseStrictUdtAssemblyLoad,
  drops the loaded/referenced allowance.
- Legacy, via Switch.Microsoft.Data.SqlClient.UseLegacyUdtAssemblyLoad,
  restores the previous behavior as a compatibility escape hatch and
  takes precedence over Strict.

The Microsoft.SqlServer.Types exemption now pins the public key token as
well as the version, so it cannot be satisfied by a same-named assembly
on the probing path.

Independently of the mode, CheckGetExtendedUDTInfo now rejects a
resolved type that is not annotated with SqlUserDefinedTypeAttribute.
Reading custom attributes does not run a static constructor, so this is
the last point at which the driver can decline without executing any of
the type's code, and it covers every call site uniformly.

Applications with lazily-loaded custom UDT assemblies can name them
through the Microsoft.Data.SqlClient.UdtAssemblyAllowList AppContext
data element.

The known-assembly-name set is cached and invalidated only by
AppDomain.AssemblyLoad, so a server streaming distinct names costs a
hash lookup rather than a probe.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c

Addresses review feedback on the UDT assembly load hardening.

The central issue: on .NET the loader ignores the public key token in an
AssemblyName, so pinning the reference was not an enforcement boundary. A
caller could consult the policy and still be handed a same-named assembly
with a different identity. SqlAuthenticationProviderManager already
documents this for the Azure extension assembly and compensates with a
post-load check; the UDT path now does the same.

To make that impossible to forget, the load moves inside the policy.
TryResolve (decide, then let the caller load) is replaced by TryLoad,
which decides, loads, and verifies that the assembly the loader returned
carries the identity the decision required. IsPermitted exposes the
decision half for tests that use names with no file on disk.

Also in the policy:

- Pin the culture of Microsoft.SqlServer.Types to neutral. It was left
  server-controlled, so a Culture= in the reference could steer the bind.
- Distinguish an omitted public key token from an explicit
  PublicKeyToken=null in allow list entries. AssemblyName represents the
  first as null and the second as a zero-length array, and treating them
  alike silently widened an entry written to pin an unsigned assembly
  into one accepting any identity.
- Hold weak references to observed assemblies, and scope the
  already-loaded tier to the driver's own AssemblyLoadContext. Strong
  references would let a server force the map to be built with one denied
  UDT and thereby pin unrelated plugin assemblies, preventing a
  collectible context from unloading.

The SMI path gains the SqlUserDefinedTypeAttribute gate it was missing.
It applied the assembly policy but not the type check, so a bare or
permitted non-UDT name could still reach ValueUtilsSmi.NullUdtInstance,
which invokes the type's static Null member. It also now traces denials,
so the documented claim that every denial is observable holds on both
paths.

Tests:

- TryLoad_LoadedAssemblyWithWrongToken_IsRefused drives the real load
  path and demonstrates the loader ignoring the requested token.
- Cover explicit PublicKeyToken=null, omitted token, and culture pinning.
- Assert the policy denial specifically rather than only that nothing was
  loaded. Because the hostile assembly does not exist, "nothing loaded"
  also passed against the vulnerable implementation.
- Add a positive control so the denial tests cannot pass by resolution
  being broken outright.
- Assert the referenced-but-unloaded precondition instead of returning
  quietly when it cannot be established.

Docs: correct the exception type to TypeLoadException, qualify the
code-execution ordering claim as measured on CoreCLR rather than stated
unconditionally, note that the attribute lookup is filtered and the
attribute sealed so it cannot itself run foreign code, and document that
trust is per process rather than per server.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c

Review raised SqlCommandBuilder and several SqlBulkCopy shapes as
possibly affected. Most are not, because they move UDT bytes without
interpreting them, but two do materialize the type and were missing from
the compatibility notes:

- SqlBulkCopy from a SqlDataReader between UDT columns, which reads each
  value to test it for INullable.
- Table-valued parameters sourced from a SqlDataReader, which build SMI
  metadata with throwing enabled.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c

Second round of review feedback on the UDT assembly load policy.

Validate the whole identity, not just the token. The decision carried
only the required public key token, so a version or culture the policy
relied on was never confirmed against what the loader returned. Measured
on net9.0: requesting System.Private.CoreLib at version 109.0.0.0 returns
9.0.0.0, which the old check accepted. Binding redirects on .NET
Framework produce the same effect. Decision now carries the required
version and culture alongside the token, and each is enforced after the
load.

Stop dependencies inheriting the already-loaded permission. The
AssemblyLoad handler recorded every assembly that arrived after the map
was built, including those pulled in by the policy's own Assembly.Load
for a permitted assembly. A server could then name one of those
dependencies and have it permitted as "already loaded", which is exactly
the transitive trust the policy documents as denied. Policy-triggered
loads are now marked with a counted thread-static guard and excluded.

Cover the SMI path. The attribute gate and resolver added there had no
tests; all end-to-end coverage went through CheckGetExtendedUDTInfo.
Added denied-assembly, bare non-UDT, and valid-UDT cases against
SmiMetaData.Type.

Fix two defects in the identity test:

- It returned without asserting when the test assembly is strong-name
  signed, so official signed builds silently lost the coverage. It now
  uses a framework assembly and does not depend on signing at all.
- It asserted the .NET shape only. On .NET Framework the loader enforces
  the strong name during binding and throws rather than returning the
  wrong assembly, so it would have failed on net462. Both shapes are the
  same refusal and both are now accepted, which also keeps the post-load
  check from regressing unnoticed on .NET.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c

AppContext.GetData does not exist on .NET Framework, so the net462 leg
of the build failed with CS0117 while every .NET leg compiled fine.

AppDomain.CurrentDomain.GetData is the portable equivalent. It has been
present since .NET Framework 1.1, and on .NET it is implemented over the
same AppContext data store, so it reads values written by either
AppContext.SetData or AppDomain.SetData as well as runtimeconfig.json
configProperties. Verified all three on net9.0.

The documented way to set the allow list is unchanged: the docs already
show AppDomain.CurrentDomain.SetData, which works on both frameworks.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c

Two further findings from review, both cases where a permission granted
to one assembly could be inherited by another.

Confirm the simple name after the load. Every basis for permitting a
load rests on the simple name: it is what the allow list is matched on
and what the built-in exemption recognizes. Nothing checked it once the
loader returned, and for a simple-name allow list entry no other
component was constrained either, so SatisfiesRequiredIdentity took its
all-null early-out and accepted whatever arrived. A custom
AssemblyResolve handler or AssemblyLoadContext resolver could answer
with an unrelated assembly and have it inherit the permission. Decision
now carries the matched name and it is always verified, so the early-out
is gone.

Snapshot the loaded set before any policy-triggered load. The provenance
guard added previously only suppressed the AssemblyLoad callback, which
left the first call unprotected: the map is built lazily, so a first
request permitted by the allow list loaded before the map existed, and
the dependencies that arrived with it were then captured by the later
snapshot as though the application had brought them in. A server naming
one of them was accepted as already-loaded. TryDecide now takes the
snapshot up front, which also attaches the handler early enough that
subsequent loads are attributed rather than absorbed.

Both tests were confirmed to fail with their respective fix reverted and
to pass with it applied.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 60806d12-bdac-413c-bf83-f7c12e3cc12c